Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



iiiiiiiiiiiniiiiiiii 

(11) EP 1 239 685 A1 



(12) EUROPEAN PATENT APPLICATION 

(43) Date of publication: (51) int CI7: H04Q 7/22 

1 1 .09.2002 Bu lletin 2002/37 



(21) Application number: 02009225.0 



(22) Date of tiling: 08.06.2001 



\oH) uesignatea uontracting otates: 


• McDonnel, James Thomas Edward 


AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 


Wiltshire SN16 9NZ (GB) 


MCNLPT SE TR 


• Thomas, Andrew 


Designated Extension States: 


California 94027-1931 (US) 


AL LT LV MK RO SI 


• Wilcock, Lawrence 




Malmesbury, Wiltshire SN16 9TU (GB) 


(30) Priority: 17.06.2000 GB 0014759 






(74) Representative: Squibbs, Robert Francis et a! 


(62) Document number(s) of the earlier application(s) in 


Hewlett-Packard Limited, 


accordance with Art. 76 EPC: 


IP Section, 


01305007.5/1 164 804 


Building 3 




Fllton Road 


(71) Applicant: Hewlett-Packard Company 


Stoke Gifford, Bristol BS 34 8QZ (GB) 


Palo Alto, CA 94304 (US) 






Remarl<s: 


(72) Inventors: 


This application was filed on 25 - 04 - 2002 as a 


• TAnson, Colin 


divisional application to the application mentioned 


Frenchay, Bristol BS16 1JL (GB) 


under INID code 62. 


• Hawkes, Rycharde Jeffrey 




Bristol BS6 5PL (GB) 





(54) Service delivery method and system 



(57) A user (70) is pre-qualified for a service to be 
provided at a particular location. A service instance el- 
ement (76) is stored as Is location data (74) indicative 
of where the service is to be triggered. The service in- 
stance element (76) may be a full customised instance 
of the service delivery code or other Item that provides 
an association between the user and an instance of the 



service for which the user has been qualified. Thereaf- 
ter the location of the user (70), as indicated by a mobile 
entity associated with the user, is periodically checked 
against the location data (74) and when a location match 
is indicated, the service instance (76) for which the user 
has been qualified is executed to deliver the required 
sen/ice to the user (70). As part of service delivery, the 
stored location data (74) is modified. 
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Description 

Field of the Invention 

[0001] The present invention relates to the delivery of 
services to nnobile users in dependence on the location 
of the users. 

Background of the Invention 

[0002] Communication infrastructures suitable for 
mobile users (in particular though not exclusively, cel- 
lular radio infrastructures) have now become widely 
adopted. Whilst the primary driver has been mobile te- 
lephony, the desire to implement mobile data-based 
services over these infrastructures, has led to the rapid 
development of data-capable bearer services across 
such infrastructures. This has opened up the possibility 
of many Internet-based services being available to mo- 
bile users. 

[0003] By way of example, Figure 1 shows one fomn 
of known communication infrastructure for mobile users 
providing both telephony and data-bearer services. In 

this example, a mobile entity 20, provided with a radio 
subsystem 22 and a phone subsystem 23, communi- 
cates with the fixed infrastructure of GSM PLMN (Public 
Land Mobile Network) 1 0 to provide basic voice teleph- 
ony services. In addition, the mobile entity 20 includes 
a data-handling subsystem 25 intenworking, via data In- 
terface 24, with the radio subsystem 22 for the transmis- 
sion and reception of data over a data-capable bearer 
service provided by the PLMN; the data-capable bearer 
service enables the mobile entity 20 to communicate 
with a service system 40 connected to the public Internet 
39. The data handling subsystem 25 supports an oper- 
ating environment 26 in which applications run, the op- 
erating environment including an appropriate communi- 
cations stack. 

[0004] More particularly the fixed infrastructure 1 0 of 
the GSM PLMN comprises one or more Base Station 
Subsystems (BSS) 11 and a Network and Switching 
Subsystem NSS 12. Each BSS 11 comprises a Base 
Station Controller (BSC) 14 controlling multiple Base 
Transceiver Stations (BTS) 13 each associated with a 
respective "ceir of the radio network. When active, the 
radio subsystem 22 of the mobile entity 20 communi- 
cates via a radio link with the BTS 1 3 of the cell in which 
the mobile entity is currently located. As regards the 
NSS 12, this comprises one or more Mobile Switching 
Centers (MSC) 1 5 together with other elements such as 
Visitor Location Registers 32 and Home Location Reg- 
ister 32. 

[0005] When the mobile entity 20 is used to make a 
normal telephone call, a traffic circuit for carrying digi- 
tised voice is set up through the relevant BSS 11 to the 
NSS 12 which is then responsible for routing the call to 
the target phone (whether in the same PLMN or in an- 
other network). 



[0006] With respect to data transmission to/from the 
mobile entity 20, in the present example three different 
data-capable bearer services are depicted, though other 
possibilities exist. A first data-capable bearer service is 

5 available in the forni of a Circuit Switched Data (CSD) 
service; in this case a full traffic circuit is used for carry- 
ing data and the MSC 32 routes the circuit to an Inter- 
Worklng Function IWF 34 the precise nature of which 
depends on what Is connected to the other side of the 

10 IWF. Thus, IWF could be configured to provide direct 
access to the public Internet 39 (that is, provide func- 
tionality similar to an LAP - Internet Access Provider 
lAP). Alternatively, the IWF could simply be a modem 
connecting to a PSTN; in this case, Internet access can 

15 be achieved by con nectlon across the PSTN to a stand- 
ard lAP. 

[0007] A second, low bandwidth, data-capable bearer 
service is available through use of the Short Message 
Service that passes data carried in signalling channel 

20 slots to an SMS unit which can be arranged to provide 
connectivity to the public Internet 39. 
[0008] A third data-capable bearer service is provided 
in the form of GPRS (General Packet Radio Service 
which enables IP (or X.25) packet data to be passed 

25 from the data handling system of the mobile entity 20, 
via the data interface 24, radio subsystem 21 and rele- 
vant BSS 11, to a GPRS network 17 of the PLMN 10 
(and vice versa). The GPRS network 1 7 includes a SG- 
SN (Serving GPRS Support Node) 18 interfacing BSC 

30 14 with the network 1 7, and a GGSN (Gateway GPRS 
Support Node) interfacing the network 17 with an exter- 
nal network (in this example, the public Internet 39). Full 
details of GPRS can be found in the ETSI (European 
Telecommunications Standards Institute) GSM 03.60 

35 speclffcation. Using GPRS, the mobile entity 20 can ex- 
change packet data via the BSS 11 and GPRS network 
1 7 with entitles connected to the public Internet 39. 
[0009] The data connection between the PLMN 10 
and the Internet 39 will generally be through a firewall 

40 35 with proxy and/or gateway functionality. 

[0010] Different data-capable bearer services to 
those described above may be provided, the described 
services being simply examples of what is possible. 
[001 1 ] In Figure 1 , a sen/ice system 40 is shown con- 

^5 nected to the Internet 40, this servk:e system being ac- 
cessible to the OS/application 26 running In the mobile 
entity by use of any of the data-capable bearer services 
described above. The data-capable bearer services 
could equally provide access to a service system that is 

50 within the domain of the PLMN operator or is connected 
to another public or private data network. 
[0012] With regard to the OS/applicatlon software 26 
running in the data handling subsystem 25 of the mobile 
entity 20, this could, for example, be a WAP application 

55 running on top of a WAP stack where "WAP" is the Wire- 
less Application Protocol standard. Details of WAP can 
be found, for example, in the book "Official Wireless Ap- 
plication Protocol" Wireless Application Protocol Forum, 
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Ltd published 1999 Wiley Computer Publishing. Where 
the OS/application software Is WAP compliant, the fire- 
wall will generally also serve as a WAP proxy and gate- 
way. Of course, OS/application 26 can comprise other 
functionality (for example, an e-mail client) Instead of, 
or additional to, the WAP functionality. 
[0013] The mobile entity 20 may take many different 
forms. For example, it could be two separate units such 
as a mobile phone (providing elements 22-24) and a mo- 
bile PC (data-handling system 25) coupled by an appro- 
priate link (wireline, infrared or even short range radio 
system such as Bluetooth). Alternatively, mobile entity 
20 could be a single unit such as a mobile phone with 
WAP functionality. Of course, if only data transmission/ 
reception is required (and not voice), the phone func- 
tionality 24 can be omitted; an example of this Is a PDA 
with built-in GSM data-capable functionality whilst an- 
other example is a digital camera (the data-handling 
subsystem) also with built-in GSM data-capable func- 
tionality enabling the upload of digital images from the 
camera to a storage server. 

[0014] Whilst the above description has been given 
with reference to a PLMN based on GSM technology, it 
will be appreciated that many other cellular radio tech- 
nologies exist and can typically provide the same type 
of functionality as described for the GSM PLMN 10. 
[001 5] Recently much interest has been shown in "lo- 
cation-based", "location-dependent", or "location- 
aware" sen/ices for mobile users, these being sen^ices 
that take account of the current location of the user (or 
other mobile party). The most basic fonm of this service 
is the emergency location service whereby a user In 
trouble can press a panic button on their mobile phone 
to send an emergency request-for-assistance message 
with their location data appended. Another well known 
location-based service is the provision of traffic and 
route-guiding information to vehicle drivers based on 
their cunrent position. A further known servkie is a "yel- 
low pages" service where a user can find out about 
amenities (shops, restaurants, theatres, etc.) local to 
their current location. The term "location-aware servic- 
es" will be used herein to refer generically to these and 
similar services where a location dependency exists. 
[0016] Location-aware services all require user loca- 
tion as an input parameter. A number of methods al- 
ready exist for determining the location of a mobile user 
as represented by an associated mobile equipment. Ex- 
ample location-determining methods will now be de- 
scribed with reference to Figures 2 to 5. As will be seen, 
some of these methods result in the user knowing their 
location thereby enabling them to transmit it to a loca- 
tion-aware service they are interested in receiving, 
whilst other of the methods result in the user's location 
becoming known to a network entity from where it can 
be supplied directly to a location-aware service (gener- 
ally only with the consent of the user concerned). It is to 
be understood that additional methods to those illustrat- 
ed In Figures 2 to 5 exist. 



[0017] As well as location determination, Figures 2 to 
5 also illustrate how the mobile entity requests a loca- 
tion-aware service provided by service system 40. In the 
present examples, the request is depicted as being 

5 passed over a cellular mobile network (PLMN 1 0) to the 
service system 40. The PLMN is, for example, similar to 
that depicted in Figure 1 with the service request being 
made using a data-capable bearer service of the PLMN. 
The service system 40 may be part of the PLMN itself 

10 or connected to it through a data network such as the 
public Intemet. It should, however, be understood that 
infrastructure other than a cellular network may attema- 
tively be used for making the service request 
[0018] The location-determining method illustrated in 

15 Figure 2 uses an inertial positioning system 50 provided 
in the mobile entity 20A, this system 50 determining the 
displacement of the mobile entity from an Initial refer- 
ence position. When the mobile entity 20A wishes to in- 
voke a location-aware service, it passes its current po- 

20 sition to the corresponding service system 40 along with 
the service request 51 . This approach avoids the need 
for an infrastructure to provide an external frame of ref- 
erence; however, cost, size and long-term accuracy 
concerns currently make such systems unattractive for 

25 incorporation into mass-market handheld devices. 
[0019] Figure 3 shows two different location-deter- 
mining methods both involving the use of local, fixed- 
position, beacons here shown as infra-red beacons IRD 
though other technologies, such as short-range radio 

30 systems (in particular, "Bluetooth" systems) may equally 
be used. The right hand half of Figure 3 show a number 
of independent beacons 55 that continually transmit 
their individual locations. Mobile entity 20B is arranged 
to pick up the transmissions from a beacon when suffi- 

35 ciently close, thereby establishing its position to the ac- 
curacy of its range of reception. This location data can 
then be appended to a request 59 made by the mobile 
entity 208 to a location-aware service available from 
service system 40. A variation on this arrangement is 

40 for the beacons 55 to transmit information which whilst 
not directly location data, can be used to look up such 
data (for example, the data may be the Internet home 
page URL of a store housing the beacon 55 concemed, 
this home page giving the store location - or at least 

45 identity, thereby enabling look-up of location in a direc- 
tory service). 

[0020] In the left-hand half of Figure 3, the IRB bea- 
cons 54 are all connected to a network that connects to 
a location server 57. The beacons 54 transmit a pres- 

so ence signal and when mobile entity 20C is sufficiently 
close to a beacon to pick up the presence signal, it re- 
sponds by sending its identity to the beacon. (Thus, in 
this embodiment, both the beacons 54 and mobile entity 
20C can both receive and transmit IR signals whereas 

55 beacons 55 only transmit, and mobile entity 208 only 
receives, I R signals). Upon a beacon 54 receiving a mo- 
bile entity's identity, it sends out a message over network 
56 to location server 57, this message linking the identity 
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of the mobile entity 20C to the location of the relevant 
beacon 54. Now when the mobile entity wishes to Invoke 
a location-aware service provided by the service system 
40, since it does not know its location it must include it's 
identity in the service request 58 and rely on the service 5 
system 40 to look up the current location of the mobile 
entity in the location server 57. Because location data 
Is personal and potentially very sensitive, the location 
server 57 will generally only supply location data to the 
service system 40 after the latter has produced an au- io 
thorizing token supplied by the mobile entity 20B in re- 
quest 58. It will be appreciated that whilst sen/ice system 
40 is depicted as handling service requests fonn both 
types of mobile entity 20 B and 20C, separate systems 
40 may be provided for each mobile type (this Is likewise is 
true in respect of the sen^lce systems depicted In Fig- 
ures 4 and 5). 

[0021] Figure 4 depicts several forms of GPS loca- 
tion-determining system. On the left-hand side of Figure 
4, a mobile entity 20D is provided with a standard GPS 20 
module and is capable of determining the location of en- 
tity 20D by picking up signals from satellites 60. The en- 
tity 20D can then supply this location when requesting, 
in request 61 , a location-aware servfce from service sys- 
tem 40. 25 
[0022] The right-hand side of Figure 4 depicts, in re- 
lation to mobile entity 20E, two ways in which assistance 
can be provided to the entity in deriving location from 
GPS satellites. Firstly, the PLMN 10 can be provided 
with fixed GPS receivers 62 that each continuously keep so 
track of the satellites 60 visible from the receiver and 
pass infonnation In messages 63 to local mobile entities 
20E as to where to look for these satellites and estimat- 
ed signal arrival times; this enables the mobile entities 
20E to substantially reduce acquisition time for the sat- 35 
ellites and increase accuracy of measurement (see "Ge- 
olocation Technology Pinpoints Wireless 911 calls with- 
in 15 Feet" 1-Jul-99 Lucent Technologies, Bell Labs). 
Secondly, as an alternative enhancement, the process- 
ing load on the mobile entity 20E can be reduced and 40 
encoded jitter removed using the services of network 
entity 64 (in or accessible through PLMN 10). 
[0023] One the mobile unit 20E has detemiined its lo- 
cation, it can pass this infonnation in request 65 when 
invoking a location-aware service provided by service ^5 
system 40. 

[0024] Figure 5 depicts two general approaches to lo- 
cation detemiinatlon from signals present in a cellular 
radio infrastructure. First, it can be noted that in general 
both the mobile entity and the network will know the so 
identity of the cell in which the mobile entity currently 
resides, this infomrjation being provided as part of the 
normal operation of the system. (Although in a system 
such as GSM, the network may only store curent loca- 
tion to a resolution of a collection of cells known as a 55 
"location area", the actual current cell ID will generally 
be derivable from monitoring the signals exchanged be- 
tween the BSC 14 and the mobile entity). Beyond cur- 



rent basic cell ID, it is possible to get a more accurate 
fix by measuring timing and/or directional parameters 
between the mobile entity and multiple BTSs 13, these 
measurement being done either in the network or the 
mobile entity (see, for example, International Applica- 
tion WO 99/04582 that describes various techniques for 
effecting location determination In the mobile and WO 
99/55114 that describes location detemiination by the 
mobile network in response to requests made by loca- 
tion-aware applications to a mobile location center - 
server- of the mobile networi<), 
[0025] The left-hand half of Figure 5 depicts the case 
of location determination being done in the mobile entity 
20F by, for example, making Observed Time Difference 
(OTD) measurements with respect to signals from BTSs 
13 and calculating location using a knowledge of BTS 
locations. The location data is subsequently appended 
to a service request 66 sent to service system 40 in re- 
spect of a location-aware service. The calculation load 
on mobile entity 20F could be reduced and the need for 
the mobile to know BTS locations avoided, by having a 
network entity do some of the work. The right-hand half 
of Figure 5 depicts the case of location determination 
being done in the network, for example, by making Tim- 
ing Advance measurements for three BTSs 13 and us- 
ing these measurements to derive location (this deriva- 
tion typically being done in a unit associated with BSC 
14). The resultant location data is passed to a location 
server 67 from where It can be made available to au- 
thorised sen^ices. As for the mobile entity 20C in Figure 
3, when the mobile entity 20G of Figure 5 wishes to in- 
voke a location-aware service available on service sys- 
tem 50, it sends a request 69 including an authorisation 
token and its ID (possible embedded in the token) to the 
service system 40; the service system then uses the au- 
thorisation token to obtain the current location of the mo- 
bile entity 20G from the location server 67. 
[0026] In the above examples, where the mobile entity 
Is responsible for determining location, this will generally 
be done only at the time the location-aware service is 
being requested. Where location detemnination is done 
by the infrastructure, it may be practical for systems cov- 
ering only a limited number of users (such as the system 
illustrated in the left-hand half of Figure 2 where a 
number of infrared beacons 54 will cover a generally 
fairly limited) for location-data collection to be done 
whenever a mobile entity is newly detected by an IRB, 
this data being passed to location server 57 where it is 
cached for use when needed. However, for systems 
covering large areas with potentially a large number of 
mobile entities, such as the Figure 5 system, it Is more 
efficient to effect location detemriination as and when 
there Is a perceived need to do so; thus, location deter- 
mination maybe triggered by the location server 67 in 
response to the service request 68 from the mobile en- 
tity 20G or the mobile entity may, immediately prior to 
making request 68, directly trigger BSC 14 to effect a 
location detemiination and feed the result to location 
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server 67. 

[0027] Further with respect to the location servers 57, 
67. whilst access authorisation by location-aware serv- 
ices has been described as being through authorisation 
tokens supplied by the mobile entities concerned, other 
authorisation techniques can be used. In particular, a 
location-aware service can be prior authorised with the 
location server in respect of particular mobile entities; in 
this case, each request from the service for location data 
needs only to establish that the request comes from a 
service authorised in respect of the mobile entity for 
which the location data is requested. 
[0028] As already indicated, Figures 2 to 5 depict only 
some examples of how location detennination can be 
achieved, there being many other possible combina- 
tions of technology used and where in the system the 
location-detennining measurements are made and lo- 
cation is calculated, stored and used Thus, the loca- 
tion-aware service may reside in the mobile entity 
whose location is of interest, in a networt<-connected 
sen/ice system 40 (as illustrated), or even in another 
mobile entity. Furthennore, whilst in the examples of 
Figures 2 to 5, invocation of the location-aware sen/ice 
has been by the mobile entity whose location is of inter- 
est, the nature of the location- aware service maybe 
such that it is invoked by another party (including, po- 
tentially, the PLMN itself). In this case, unless the invok- 
ing party already knows the location of he mobile entity 
and can pass this information to the location-aware 
service (which may, for example, maybe situation where 
the PLMN invokes the service), it is the location-aware 
service that is responsible for obtaining the required lo- 
cation data, either by sending a request to the mobile 
entity itself or by requesting the data from a location 
server. Unless the location server already has the need- 
ed information in cache, the server proceeds to obtain 
the data either by inten-ogatlng the mobile entity or by 
triggering infrastructure elements to locate the mobile. 
For example, where a location-aware service running 
on sen/ice system 40 in Figure 5 needs to find the loca- 
tion of mobile 20G, it could be arranged to do so by re- 
questing this information from location server 67 which 
in turn requests the location data from the relevant BSC, 
the latter then making the necessary determination us- 
ing measurements from BTSs 13. 
[0029] Although in the foregoing, the provision of lo- 
cation data through the mobile radio infrastructure to the 
mobile entity has been treated as a service effected over 
a data-capable bearer channel, it may be expected that 
as location data becomes considered a basic element 
of mobile radio infrastructure services, provision will be 
made in the relevant mobile radio standards for location 
data to be passed over a signalling channel to the mobile 
entity. 

[0030] US 6,01 1 .973 discloses a mobile phone that is 
arranged to be enabled or disabled according to its lo- 
cation, data about the allowability of operation of the mo- 
bile phone in various geographical locations being 



stored either in the phone or elsewhere. WO-A- 
97/41654 describes the location -based triggering of in- 
fomiation services to registered customers. US 
5,568,153 discloses a system where the parameters of 

5 a service are determined on the basis of the user's cur- 
rent location, this being done after service delivery is 
requested. WO-A-99/67904 describes paying for an 
electronk: access key to an event, the key being stored 
in a handset until required. US 6,236,981 discloses an 

10 arrangement where tokens are stored in a Garnet and 
spent by transfer to an on-line merchant. 
[0031] It is an object of the present Invention to pro- 
vide an improved method and system for service deliv- 
ery to mobile users. 

15 

Summary of the Invention 

[0032] According to one aspect of the present inven- 
tion, there is provided a service delivery method com- 
20 prising the steps of: 

(a) qualifying a user as authorised to benefit from 
an instance of a particular service, and storing: 

25 . location data Indicative of at least one location 
where service delivery is to be triggered, and 
a service instance element that associates the 
user and the service instance for which the user 
has been qualified; 

30 

(b) subsequently detecting a location match be- 
tween the location of the user, as indicated by the 

location of a mobile entity associated with the user, 
and a location indicated by said location data, and 
35 thereupon initiating delivery to the user of the serv- 
ice instance associated with the user by the service 
instance element; and 

(c) modifying the location data as part of delivery of 
the service instance initiated In step (b). 

40 

[0033] The present invention also envisages a service 
delivery system for effecting service delivery in accord- 
ance with the foregoing method. 

^5 Brief Description of the Drawings 

[0034] A service delivery method and system, both 
embodying the present invention, will now be described, 
by way of non-limiting example, with reference to the 
50 accompanying diagrammatic drawings, in which: 

. Figure 1 is a diagram of a known communications 
infrastructure usable for transferring 
vofce and data to/from a mobile entity; 
55 . Figure 2 is a diagram illustrating one known ap- 
proach to determining the location of a 
mobile entity, this approach involving 
providing the entity with an inertial posi- 
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tioning system; 

. Figure 3 is a diagram illustrating another l<nown 
approacli to determining the location of 
a mobile entity, this approach being 
based on proximity of the mobile entity s 
to fixed-position local beacons; 

. Figure 4 is a diagram illustrating a further known 
approach to determining the location of 
a mobile entity, this approach involving 
the use of GPS satellites; io 

. Figure 5 is a diagram illustrating a still further ap- 
proach to determining the location of a 
mobile entity, this approach being based 
on the use of signals present in a cellular 
mobile radio communications system; is 

. Figure 6 is a diagram illustrating the main logical 
components of a service delivery meth- 
od and system embodying the invention; 

. Figure 7 is a diagram illustrating a first specific 

embodiment of the Invention; 20 

. Figure 8 Is a diagram Illustrating a second specific 
embodiment; 

. Figure 9 is a diagram illustrating a third specific 

embodiment; and 
. Figure 10 is a diagram illustrating a fourth specific 25 

embodiment. 

Best iWode of Carrying Out the Invention 

[0035] Service delivery methods and systems em- 30 
bodying the Invention will now be described with refer- 
ence to Figures 6 to 10. The specific embodiments of 
Figures 7 to 10 depict a user with a cellular mobile de- 
vice and a mobile infrastructure with a location server 
for providing location data about mobile users; the spe- 35 
cific embodiments shown in Figures 7 to 9 also depict a 
service system 40 connected to the public Internet 39. 
It is to be understood that the present Invention Is not 
limited to the specifics of the mobile entity, location dis- 
covery means or communication infrastructure shown 40 
In the Figures and the generalisations discussed above 
in relation to Figures 1 to 5 regarding these elements 
apply equally to the operational context of the described 
embodiments of the invention. Thus, whilst the service 
system 40 in Figures 7 to 9 is shown as connected to 45 
the public Internet, It could be connected to a GPRS net- 
work 1 7 or to another fixed data network interfacing di- 
rectly or Indirectly with the network 17 or network 39. 
Furthermore, communication between the user's mobile 
entity and a service system can be via a communication 50 
infrastructure that does not use cellular radio; for exam- 
ple, a short-range wireless system could be used. 
[0036] Consideration will first be given to the gener- 
alised embodiment of the service delivery method 
shown In Figure 6. In Figure 6 a user entity 70 Is depicted 55 
which comprises a user and a mobile device through 
which the location of the user can be ascertained (for 
example, a mobile entity 20 such as shown in Figures 



2 to 5). For convenience, the term "user entity" will be 
used both for actions/events Involving only the device 
itself and action s/events involving the user acting 
through the mobile device; the reference 70 will be used 
both for the user entity and for the user alone. 

[1] - When the user 70 subscribes to a service or 
buys a product with which a sen^ice is associated, 
the service seller, acting through a service factory 
client 71 , causes an executable service instance 76 
to be created by a service factory 72 associated with 
the service. The service instance is an embodiment 
of the behavlorassoclated with the purchased serv- 
ice. The service Instance is associated with a set of 
well-defined locations that are of interest to the 
service. These locations are specified in location 
descriptors 74 that either specify locations or polyg- 
onal areas, either as a set of x.y coordinates, or as 
a set of high-level semantk; representations such 
as "Lloyds Bank. Bristol" that can be mapped to 
physteal locations. Each user has a Service Repos- 
itory 75 to hold the current set of service instances 
76 active for the user's context. The Location De- 
scriptors 74 associated with the service instances 
of the user are held in a Location Descriptor Repos- 
itory 73. 

[2J - The newly created service Instance 76 and an 
initial set of one or more location descriptors 74 to 
be applied to the service, are downloaded respec- 
tively to the Service Repository 75 and Location De- 
scriptor Repository 73 of the user. The service re- 
mains dormant until the location of the user entity 
70 matches one of the locations defined by the Lo- 
cation Descriptors defined for the service. 

[3] - The physical location of the user entity 70 is 
obtained by a location source 77 in any suitable 
manner and passed on a periodic basis to a Loca- 
tion Comparator Engine 78. 

[4] - The Location Comparator Engine 78 compares 
the current location of entity 70 with the set of active 
Location Descriptors 74. If a match Is found, a trig- 
ger is sent to a Service Execution Environment 79, 
this trigger Identifying the service instance to be ex- 
ecuted (for example, by combination of user ID and 
location, or by a service instance identifier held with 
the matched Location Descriptor) 

[5] - the Service Execution Environment 79 loads 
the appropriate service instance 76 and executes 
it, passing in the cun-ent location if required. The 
service may be one that once triggered, runs to 
completion regardless of subsequent changes in lo- 
cation, or one that only functions whilst the location 
matches a location descriptor. In this latter case, lo- 
cation samples are taken at Intervals and the serv- 
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Ice only continues to run for as long as the current 
location matches the Location Descriptors of the 
service. 

[6] - The service can be enabled to specify the fre- s 
quency of location updates it requires, and also 
modify the set of Location Descriptors 74 to be ap- 
plied. 

[0037] The physical location of the functional entities 
71 , 72, 73, 75, 77, 78 and 79 depends on the architec- 
ture of the network infrastnjcture used to inter-commu- 
nicate the entities and the capabilities of the mobile de- 
vice of user entity 70. Thus, whilst the Service Factory 
72 will generally be located in the network infrastructure, 
each of the other entities could be located either on the 
mobile device or In the network. 
[0038] A possible service delivery scenario is as fol- 
lows. A customer buys an airline flight ticket. A service 
instance 76 is instantiated by the airline to identify the 
specific purchasing transaction, so that the behavior of 
the service instance can be made dependent on char- 
acteristics of the transaction. A description of the loca- 
tion trigger point(s) of the service is stored either in the 
user's mobile devrce (e.g. a cell-phone device) or in the 
cellular radio infrastructure. Assume that a trigger point 
is the airport. When the customer arrives at the airport, 
the location of the mobile device as determined by the 
cellular radio infrastructure matches the trigger point of 
the service. The servk^ instance is now activated, can 
welcome the customer by name, politely ask them to 
check In, invite and direct the customer to airiine lounge 
if the customers ticket is of the appropriate type, and 
finally remind the customer to leave the lounge when 
the flight is boarding. 

[0039] In the Figure 6 embodiment, a full executable 
servk:e instance is created by the service factory. This 
is particulariy useful where the service execution envi- 
ronment is either the mobile device or another system 
which does not have large resources or continual net- 
work access. An alternative approach is to store in- 
stance customization data that can be used to custom- 
ize generalized service code that is available to the serv- 
ice execution environment either because the latter has 
resources to store such code or can access the code 
across a network connection. 

[0040] Thus, in general terms, the service factory, 
once it is satisfied that the user has qualified for the serv- 
ice (for example, by having paid or by having appropri- 
ate attributes), generates a service instance element 
that associates the user with an instance of the service 
for which the user has been qualified. The service in- 
stance element can be a full executable code version of 
the servfce as described above in relation to Figure 6, 
customization data customizing a generalized service 
to the user, or even just an indicator that the user is en- 
titled to the benefits of a service instance whbh is not 
otherwise subject to customization. 
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[0041 ] A number of different ways can be used by the 
service instance element to associate the user and the 
service instance for which the user has been qualified.. 
One way is to have the service instance element contain 
an identifier of the user, the instance element either itself 
including the instance executable or including a refer- 
ence to the latter; in this case, the location trigger proc- 
ess results in the user identifier being produced for 
matching up with the service instance element (note that 
if multiple service instance elements are stored for the 
same user, additional Infonnatlon such as triggering lo- 
cation, may be required to distinguish between the serv- 
ice instance elements). Another way is to include a serv- 
ice instance identifier in the service instance element, 
this identifier also being associated with the user (for 
example, by being known to the user entity) and being 
produced by the location trigger process for matching 
with the service instance element. A third way of having 
the service instance element associate a user with a 
particular service instance is to store the service in- 
stance element in the user entity or other user-dedicated 
entity. 

[0042] With regard to the location triggering process, 
it will be appreciated that this can be implemented in 
many ways. For example, the location descriptors can 
be stored in a service system containing the service ex- 
ecution environment, the user's current location being 
provided to the service system by a location server 
(such as server 57 of Figure 3 or server 67 of PLMN 10 
of Figure 5) or by the user entity 70 itself (the entity 70 
having discovered its location by any of the methods de- 
puted in Figures 2 to 5, for example). Alternatively, the 
location descriptors could be stored in a location server 
57 or 67 with location matching also being effected in 
the server. Another possibility is to store the location de- 
scriptors in the user entity 70 itself, the tatter discovering 
its location by a method of Figures 2 to 5 and effecting 
the location matching process itself. 
[0043] Specific example embodiments will now be de- 
scribed with reference to Figures 7 to 10. 
[0044] In the Figure 7 embodiment, the service factory 
has loaded a service instance element (SIE) 80 into a 
database 75 of a service delivery system 40 and a cor- 
responding location descriptor 74 into a repository 73 
associated with location server 67 of PLMN 1 0. The SIE 
80 comprises, in this example, a user identifier (user ID) 
and user-specific customization data. The location de- 
scriptor 74 also includes the user ID and the location 
server 67 of PLMN understands which PLMN subscriber 
is identified by this user ID (conveniently, the user ID 
can be the IMSI associated with the user). Service sys- 
tem 40 comprises, as well as database 75, a program 
database 81 holding the generic program code for the 
services to be delivered by the system, a service exe- 
cution environment 78, a service loader 82 for loading 
the correct service program and customization data to 
provide a required service instance, and interface 41 for 
interfacing the service system with a communication in- 
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frastructure (here shown as internet 39). 
[0045] The user's mobile device is a cellular-radio mo- 
bile entity 20 such as described with reference to Figure 
1 and is capable of communicating with the service sys- 
tem 40 via a data-capable bearer service of PLMH 10 
and internet 39. When the mobile entity is in a switched- 
on state: location server 67 of PLMN 10 is capable of 
detennining the location of the mobile entity. 
[0046] In operation, upon the mobile entity 20 being 
detected by location server 67 as at a location matching 
a location descriptor 74 associated with the user, a lo- 
cation match trigger (Including user ID and possibly also 
user location) is passed from the location server 67 to 
the service loader 82 of the service system 40 (see ar- 
row 85). The service loader uses the user ID (and pos- 
sibly also the user location) to identify the con^esponding 
SIE 80. The SIE 80 identifies the service program to be 
executed and service loader 82 causes the relevant pro- 
gram to be loaded into the service execution environ- 
ment along with the customization data contained in the 
SIE 80 In order to create and run the service instance 
for which the user has been prior authorized. Execution 
of the service instance will generally (but not necessar- 
ily) involve communication between the service system 
and the user's mobile entity 20, for example using a da- 
ta-capable bearer service of PLMN 10 (see arrow 86). 
[0047] The Figure 8 embodiment is similar to that of 
Figure 7 except that now the location descriptors 74 are 
stored in mobile entity 20, each with an associated serv- 
ice instance identifier (SI ID), and the SIEs 80 stored in 
database 75 each Include a corresponding SI ID. Loca- 
tion matching between the location descriptors and the 
user's current location (as identified to the entity 20 by 
location server 67 or discovered in some other way) is 
done in the mobile entity 20. When a match is detected, 
the SI ID associated with the matched location is passed 
to the service loader 82 (see arrow 87) which looks up 
the corresponding SIE 80 in database 75 and then over- 
sees running of the appropriate service instance. If re- 
quired, the SIE 80 can include both the user ID and the 
locations where the service instance is pemnltted to be 
triggered; the service loader can then be arranged to 
confimfi (and possibly even require authentication of) the 
user's identity and the origin of the user's location frx 
(the service instance may, for example, require that only 
location fixes by location server 67 will be trusted, in 
which case the mobile entity 20 can be required to pro- 
vide digitally-signed location data from the server 67). 
[0048] In the Figure 9 embodiment, the location de- 
scriptors 74 are again stored in the mobile entity 20 
where location matching is effected. However, now the 
SIE 80 is also stored in the mobile entity 20 and takes 
the fonm of a service token that can be used to claim 
servk:e Instance delivery from a service system 40. The 
service token is associated with the user by virtue of be- 
ing stored In the mobile entity 20 and includes data iden- 
tifying the service to be provided by service system 40 
and any servbe customization data; advantageously, 



the service token also includes address (and password) 
details for contacting the service system. In operation, 
upon a location match being detected, the mobile entity 
transits the service token, via a data-capable bearer 
5 service of PLMN 10 and the internet 39, to the service 
system. At the service system, the token is passed to 
an authentication and service execution subsystem 83 
where it is used to instantiate and run the required serv- 
ice instance. 

10 [0049] Preferably, the service token includes the us- 
er's Identity and is digitally signed by the service factory 
(with a corresponding certificate being included in the 
token). In this case, the sub-system 83 can both: 

IS - check that the service token originates from a serv- 
ice factory for which it is willing to provide service 
delivery (this check involves checking the Identity 
of the signing party with the certification authority in 
standard manner); and 

20 - check that the party sending the token is the same 
as the party identified In the token (the authentk^ity 
of which is guaranteed by the digital signature). 
Checking the sending party's identity is done using 
a challenge / response mechanism by which the 

25 service system 40 sends an item of data to the mo- 
bile entity and asks it to return it signed/encrypted 
under its private key (it being assumed that the mo- 
bile entity is provided with a public key / private key 
pair that are associated with the user). This enables 

30 the service system to check the Identity of the user 
(with the user's certificate authority) and thus check 
whether the user is the same party as identified in 
the token. 

35 [0050] Of course, since the basic challenge/response 
mechanism is something that is nomially done between 
the system 40 and the mobile entity 20 without involve- 
ment of the user, the mechanism does not guard against 
the mobile entity having been stolen. As an added pre- 
40 caution, therefore, the user authentication process pref- 
erably further includes asking for the user to input a PIN 
number, this latter being known to the system 40 (such 
as by having been included in the token, possibly en- 
crypted in a manner enabling only the service system 
45 40 to decrypt It - for example, the service factory en- 
crypts the PIN using the public key of the service system 
40). 

[0051] It will be appreciated that the same authenti- 
cation process can equally be applied in full or in part to 
50 the case where the service token is replaced by a fully 
executable service instance code. 
[0052] In the Figure 10 embodiment the location de- 
scriptors 74 are again stored in the mobile entity 20 
where location matching is effected. However, now the 
55 SIE 80 comprises the full service Instance executable 
76 stored in the mobile entity 20 and intended to execute 
in the mobile entity when a location match is detected. 
No external interaction with a pre-authorised service el- 
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ement is required. Of course, external service interac- 
tions can be effected during the course of service exe- 
cution (though not shown in Figure 10). As already not- 
ed, the current location of the mobile entity can be pro- 
vided by means other than the location server 67 of s 
PLMN 1 0, for example by a built-in GPS system or from 
local location beacons, and in this case, wide-area con- 
nectivity is not required for mobile entity 20. 

Variants io 

[0053] It will be appreciated that many variants are 
possible with respect to the above described embodi- 
ments with features described in relation to one embod- 
iment also being adaptable for use with other of the em- i5 
bodrments. Thus, for example, the authentication fea- 
tures (digital signing of SIE 80 to check origin, user au- 
thentication through challenge/response mechanism, 
use of PIN) described above in relation to the Figure 9 
embodiment can also be used with the other embodi- 20 
ments. For example, where the SIE 80 is distributed by 
the service factory to a device or system under different 
control, It will generally be a good practice to have the 
SIE digitally signed by the service factory so as to enable 
the final service delivery system (system 40 in Figures 25 
7 to 9) to check the origin of the SIE 80. Again, checking 
the identity of the user requesting service execution will 
often also be prudent, using a challenge/response 
mechanism and/or PIN input. 

[0054] As noted above, the mobile entity 20 need not 30 
have wide>area connectivity. For example, communica- 
tion with service system 40 could be through a short 
range wireless link (for example, an infra-red link or a 
Bluetooth radio connection). In fact, as already indicated 
with respect to the Figure 1 0 embodiment, the mobile 35 
entity 20 need not have any external communication ca- 
pability other than to enable it to detemiine its location. 
[0055] The location descriptors and service instances 
elements can be stored by user, by service to be deliv- 
ered, or in any other suitable distribution. For example, 40 
where different service systems 40 are used for different 
services in the embodiments of Figures 7 and 8 embod- 
iments, then the database 75 of each service system 40 
will store StEs 80 relating to different users but the same 
service. 

[0056] A service instance element can be arranged to 

specify a particular number of times (including only 
once) that the associated service instance can be run, 
each running of the service instance decrementing this 
count (or incrementing a count of the number of times so 
the instance has been run). 

Claims 

55 

1 . A servk^e delivery method comprising the steps of: 
(a) qualifying a user (70) as authorised to ben- 
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efit from an instance of a particular service, and 
storing ([2]): 

location data (74) indicative of at least one 
location where service delivery is to be trig- 
gered, and 

a service Instance element (76) that asso- 
ciates the user and the service instance for 
whrch the user has been qualified; 

(b) subsequently detecting ([4]) a location 
match between the location of the user as in- 
dicated by the location of a mobile entity (20) 
associated with the user and a location indicat- 
ed by said location data (74), and thereupon in- 
itiating delivery to the user of the service in- 
stance associated with the user by the service 
Instance element (76); and 

(c) modifying the location data (74) as part of 
delivery of the service instance initiated in step 
(b). 

2. A method according to claim 1 , wherein the service 
instance element (76) is associated with the user 
by a user identifier included In the element, and with 
the service instance by either comprising code for 
implementing the instance or including a reference 
to such code, the user's mobile entity (20) directly 
or indirectly supplying this user identifier for service 
delivery to be effected. 

3. A method according to claim 1 , wherein the service 
instance element (76) Is associated with the user 
by a service-instance identifier known to the user or 
the user's mobile entity (20), the service instance 
element (76) either comprising code for implement- 
ing the service instance or including a reference to 
such code, the user's mobile entity (20) directly or 
indirectly supplying this service- instance identifier 
for service delivery to be effected. 

4. A method according to claim 1 , wherein the service 
instance element (76) is stored in a service provider 
system (40) with which the user's mobile entity can 
communk:ate through a communications infrastruc- 
ture (10), and wherein the location data (74) is 
stored in one of: 

a location server (67) of the communications in- 
frastructure (10), 

- the mobile entity (20), 

- the service provider system (40), 

where it is compared against the current location of 
the mobile entity (20) as provided by one of: 

a location server (67) associated with the com- 
munications infrastructure (1 0), 
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location discovery means of the mobile entity 
(20); 

in order to detect a said location match; the detec- 
tion of a location match causing the service provider 5 
system (40) to Identify the service Instance to be 
delivered by matching a said Identifier provided di- 
rectly or indirectly by the user's mobile entity (20) 
with said service instance element (76). 

10 

5. A method according to claim 1 , wherein the sen/ice 
instance element (76) associates the user and serv- 
ice Instance by virtue of the service instance ele- 
ment being stored in the user's mobile entity (20) 
and either comprising code for implementing the '5 
service Instance or including a reference to such 
code. 

6. A method according to claim 5, wherein the sen/Ice 
instance element Is a token (80) which upon the us* 
efs mobile entity (20) determining or being in- 
formed of a said location match, is passed by the 
mobile entity (20) over a communications infra- 
structure (10) to a service provider system (40) 
where it is used to initiate service provision to the 
user. 

7. A method according to claim 6, wherein the token 
includes user identity data and is digitally-signed by 
the party that carried out the qualification In step (a) 3o 
whereby the service provider system (40) can 
check the authenticity of the data in the token (80), 

the user mobile entity (20) having an associated 
publb-key / private-key pair and being required by 
the service provider system (40) in step (b) to au- 35 
thenticate its identity by using its private key to sign 
and return data proposed by the service provider 
system (40). 

8. A method according to any one of the preceding 40 
claims, wherein the service instance element (76) 
includes customisation data customising a generic 
service to said service instance. 

9. A method according to any one of the preceding ^5 
claims, wherein service delivery is conditional upon 
the user inputting a personal identification code. 

10. A method according to any one of the preceding 
claims, wherein the service instance element (76) 50 
is passed by the party that candles out the qualifica- 
tion in step (a) to the user or to a third-party, the 
service instance element (76) being digitally signed 

by the party that carries out the qualification in step 
(a) whereby to enable an eventual service deliverer ss 
to check the origin and authenticity of the service 
instance element. 
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